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REMARKS 

Applicants submit the present Amendment to respond to the Office Action mailed August 
11,2006. 

I. Applicant's Prior Information Disclosure Statement 

Applicants have attached hereto a complete copy of Citation No. 6 on Applicant's 
Information Disclosure Statement of July 31, 2003. This document is dated at least as early as 
April 4, 2003. This document appears to be nearly, but not quite, identical to the version of the 
document identified by the Examiner. 

II. The Objection to the Specification 

Applicants have amended the specification to correct the typographical error at page 9, 
line 24 noted in the Office Action. 

III. The Rejections Under 35 U.S.C. § 112 

Claims 6 and 20 stand rejected under 35 U.S.C. § 1 12, 1 1 as failing to comply with the 
enablement requirement. In particular, the Office Action states that the recitation "checking the 
collection registry by the link object in response to the one-to-many or many- to-many 
association not being materialized" is not described in the specification, as "Figures 6 and 7, and 
lines 3-3 1 on page 10 of the disclosure indicate that collection registry is examined directly for 
the presence of the collection, instead of trying to materialize said collection before examining 
the collection registry." (Office Action at p. 3, lj 6). Applicants respectfully traverse this 
rejection. 

Page 10, line 21 through page 13, line 5 of the specification and the drawings cited 
therein describe certain embodiments of the present invention which include intelligent objects 
that are known as link objects or simply as "links." Claims 6 and 20 each recite such link 
objects. With respect to the enablement rejection, Applicants call the Examiner's attention to 
page 11, lines 13-21 and page 12, lines 6-14 of the present specification. These excerpts recite: 

Each link factory can maintain a collection registry to reference the target collection of 
source EJBs while they are passivated. When the one-to-many or many-to-many 
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relationship of a reactivated bean is traversed, the link for the relationship can check its 
registry and return the existing registered target collection if it is present. If the collection 
is not present in the registry, then the link can materialize the target collection from the 
database. 

* * # 

As shown in Figure 10, at Block 1010, a determination is made as to whether the link 
object detects the collection of target EJBs in its collection registry 410. In particular, 
each link factory 810 can maintain a collection registry to reference the target collection 
of source EJBs while they are passivated. When the one-to-many or many-to-many 
relationship of a reactivated EJB is traversed, the link for the relationship will check its 
registry at Block 1010. As shown at Block 630, the link object will return the existing 
registered target collection if it is contained in the collection registry 410. As shown 
at Block 720, if the collection is not present in the collection registry, then the link 
will materialize the target collection from the database . 

(Emphasis added). Applicants respectfully submit that the specification at page 10, line 21 
through page 13, line 5, as evidenced by the above excerpts thereof, fully enables the inventions 
recited in Claims 6 and 20 and, accordingly, Applicants respectfully request withdrawal of the 
rejections under 35 U.S.C. § 112, ^ 1. 

IV. The Rejections Under 35 U.S.C. § 101 

Claims 9 and 15 stand rejected under 35 U.S.C. § 101 as being directed to non-statutory 
subject matter. Applicants also respectfully traverse these rejections. 

With respect to Claim 9, the Office Action states that the "module" recited therein can be 

implemented (according to the specification) entirely as software components, and that "software 

is considered functional descriptive material and functional descriptive material perse is 

considered non-statutory subject matter by the Office." (Office Action at pp. 3-4, ^ 7). 

However, Claim 9 is not directed merely to software, but instead is directed to a system for 

maintaining association integrity of Enterprise JavaBeans (EJBs) during EJB passivation and 

reactivation that includes a collection registry and the module. As provided in the MPEP: 

Computer programs are often recited as part of a claim. Office personnel should 
determine whether the computer program is being claimed as part of an otherwise 
statutory manufacture or machine. In such a case, the claim remains statutory irrespective 
of the fact that a computer program is included in the claim. The same result occurs when 
a computer program is used in a computerized process where the computer executes the 
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instructions set forth in the computer program. Only when the claimed invention taken 
as a whole is directed to a mere program listing, i.e., to only its description or 
expression, is it descriptive material per se and hence nonstatutory . 

Since a computer program is merely a set of instructions capable of being executed by a 
computer, the computer program itself is not a process and Office personnel should treat 
a claim for a computer program, without the computer-readable medium needed to 
realize the computer program's functionality, as nonstatutory functional descriptive 
material. When a computer program is claimed in a process where the computer is 
executing the computer program's instructions, Office personnel should treat the claim as 
a process claim. See paragraph IV. B. 2(b), below. When a computer program is recited 
in conjunction with a physical structure , such as a computer memory, Office 
personnel should treat the claim as a product claim . See paragraph IV.B.2(a), below. 

(MPEP 2106, emphasis added). In any event, Applicants have amended Claim 9 to further recite 
a "computer usable storage medium" and to recite that the module "includes computer readable 
program code that is embodied in the computer usable storage medium." Thus, as amended, 
Claim 9 is directed to a system for maintaining association integrity of Enterprise JavaBeans 
(EJBs) during EJB passivation and reactivation that includes a collection registry, a computer 
usable storage medium and the module, and hence clearly is directed to more than just a 
computer program. Accordingly, the rejection of Claim 9 under 35 U.S.C. § 101 should be 
withdrawn. 

Claim 15 is rejected because the specification identifies "transmission media" as a 
possible computer useable storage medium. (Office Action at p. 4, \ 7). In particular, this 
statement from the specification has been interpreted in the Office Action as including a 
transmission medium, which the Office Action states comprise an intangible medium that is non- 
statutory subject matter. Applicants respectfully traverse this rejection. 

Claim 15 is directed to a computer program product that includes a computer usable 
storage medium having computer readable program code means embodied in the medium. 
Applicants respectfully submit that persons of skill in the art will appreciate that the statement in 
the specification regarding "transmission media" is directed to transmission hardware/software 
such as the hardware/software that supports Internet or intranet communications. The 
"transmission media" referred to in the specification is expressly described as a "computer 
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readable medium." Persons of skill in the art will appreciate that carrier waves existing in space 
do not comprise a "computer readable medium", but instead only become computer readable 
when down-converted, demodulated, decoded and the like by transmission media 
hardware/software. Accordingly, the "transmission media" referred to in the specification and 
covered by Claim 15 comprises tangible transmission hardware/software that comprises statutory 
subject matter under 35 USC §101. 

V, The Rejections Under 35 U.S.C. § 102 

Claims 1-4, 9-12, 15-18 and 21-22 stand rejected as anticipated under 35 U.S.C. § 102 by 

the BEA Systems article. (Office Action at p. 4, ^ 9). 

A. The Rejections of Independent Claims 1,15 and 21 

Independent Claim 1 stands rejected as anticipated under 35 U.S.C. § 102 by the BEA 

Systems article. (Office Action at p. 4, f 9). In particular, the Office Action states that: 

"BEA Systems discloses the method of maintaining association integrity of Enterprise 
JavaBeans (EJB) comprising: 

a) obtaining a collection of target EJBs that are associated with a source EJB (Pg 11, 
paragraph 7)("loading related beans"); and 

b) registering the collection of target EJBs in a collection registry (Pg 11, paragraph 
7 and Pg 12, paragraph 3)(The 'cache' serves as a dedicated location for the 
related beans)." 

(Office Action at pp. 4-5, f 9). Applicants respectfully traverse this rejection. 

As an initial matter, the rejection of Claim 1 fails to identify where in BEA Systems 
numerous recitations of Claim 1 are taught or disclosed. In particular, Claim 1 recites: 

1 . A method of maintaining association integrity of Enterprise JavaBeans 
(EJBs) duriae EJB passivation and reactivation comprising: 

obtaining a collection of target EJBs that are associated with a source EJB in a 
one-to-many or many-to-many association in response to traversing the 
one-to-many or many-to-many association of the source EJB ; and 

registering the collection of target EJBs that are associated with a source EJB in 
a one-to-many or many-to-many association in a collection registry. 



In re: Salo et al. 
Application No.: 10/632,157 
Filed: July 31/2003 
Page 14 

(Emphasis added). Applicants respectfully submit that the Office Action does not identify where 
BEA Systems discloses each of the above-emphasized recitations of Claim 1. Moreover, 
Applicants' have reviewed the cited portions of BEA Systems and respectfully submit that they 
fail to disclose or suggest any of the above-emphasized recitations of Claim 1. In particular, the 
cache of BEA Systems does not act to maintain association integrity of EJBs during EJB 
passivation and reactivation, but instead is simply a location for storing activated beans. 
Likewise, BEA Systems does not disclose obtaining a collection of target EJBs in response to 
traversing the one-to-many or many- to-many association of the source EJB. The cited portions 
of BEA Systems likewise do not involve registering a collection of target EJBs with a source 
EJB in a collection registry. As a rejection under 35 U.S.C. § 102 requires that the cited 
reference disclose each and every recitation of the claim at issue, Applicants respectfully submit 
that the rejection of Claim 1 should be withdrawn, as BEA Systems fails to disclose or suggest at 
least the three (3) above-emphasized recitations of Claim 1 . 

hi addition, Applicants respectfully submit that the cited portions of BEA Systems also 
do not disclose or suggest a "method of maintaining association integrity of Enterprise 
JavaBeans" as recited in Claim 1. Instead, the cited portions of BEA Systems involve 
"relationship caching of entity beans" which may avoid multiple queries. Accordingly, the 
rejection of Claim 1 should be withdrawn for this reason as well. Claim 15 is a computer 
program product claim counterpart to the method of Claim 1 and Claim 21 is a system 
counterpart to the method of Claim 1, and hence the rejections of Claims 15 and 21 should be 
withdrawn for the same reasons that the rejection of Claim 1 should be withdrawn. 

B. The Rejection of Independent Claim 9 

Independent Claim 9 likewise stands rejected as anticipated by BEA Systems. Claim 9 

recites: 

9. A system for maintaining association integrity of Enterprise JavaBeans 
(EJBs) during EJB passivation and reactivation comprising: 
a collection registry; and 
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a module that is configured to obtain a collection of target EJBs that are 
associated with a source EJB in a one-to-many or many-to-many association in response 
to traversing the one-to-many or many-to-many association of the source EJB, and to 
register the collection of target EJBs that are associated with a source EJB in a 
one-to-many or many-to-many association in the collection registry. 
The rejection of Claim 9 likewise fails to identify anything in the cited portions of BEA Systems 
that disclose or suggest obtaining the collection of target EJBs "in response to traversing the 
one-to-many or many-to-many association of the source EJB" as recited in Claim 9, nor do the 
cited portions of BEA Systems disclose or suggest a "system for maintaining association 
integrity of Enterprise JavaBeans (EJBs) during EJB passivation and reactivation." Accordingly, 
the rejection of Claim 9 should be withdrawn for at least these reasons. 

C. The Rejections of the Dependent Claims 

Each of the remaining claims depend upon one of Claims 1, 9, 15 or 21. Accordingly, 
each of these claims are patentable for at least the reasons, discussed above, that the claim from 
which they depend is patentable over BEA Systems. In addition, Applicants respectfully submit 
that BEA Systems fails to disclose or suggest the recitations added by any of the dependent 
claims, and hence submit that each dependent claim is also independently patentable over the 
cited art. 

For example, Claims 2 and 16 recite that the registering comprises "registering the 
collection of target EJBs that are associated with a source EJB in a one-to-many or 
many-to -many association in a collection registry in response to passivation of the source EJB." 
The Office Action cites to page 4, paragraph 1 of BEA Systems as disclosing this recitation. 
However, the cited portion of BEA Systems refers to storing an EJB on disk during passivation 
(i.e., the disk of BEA Systems is being cited as corresponding to the collection registry of Claims 
1 and 2). However, in the rejection of Claim 1, the cache - as opposed to the disk - is identified 
as the collection registry of Claim 1 . As such, the rejections of Claims 1 and 2 are inconsistent. 
Moreover, the cache of BEA Systems is something that stores activated EJBs, as is clearly 
shown in Figure 4-2 and accompanying description on page 3 of BEA Systems, and hence the 
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cashe of BE A Systems cannot correspond to the collection registry of Claim 2. Accordingly, the 
rejections of Claims 2 and 16 should be withdrawn for at least these additional reasons. 

BEA Systems likewise fails to disclose the recitations of Claims 3 and 17. For example, 
each of these claims recites "fetching the collection of target EJBs that are associated with the 
source EJB that is reactivated from the collection registry in response to traversing the 
one-to-many or many-to-many association of the source EJB that is reactivated." The Office 
Action cites the "relationship caching" function of BEA Systems as teaching this recitation of 
Claim 3. (Office Action at p. 5, If 9). However, the relationship caching function of BEA 
Systems appears to involve loading a group of related beans into the cache when a bean is 
reactivated. It clearly does not involve fetching target EJBs from a collection registry in 
response to traversing the one-to-many or many-to-many association of the source EJB that is 
reactivated" as recited in Claims 3 and 17. Accordingly, the rejections of Claims 3 and 17 
should be withdrawn for at least these additional reasons. 

Claim 10 recites that "the module is configured to register the collection of target EJBs 
that are associated with a source EJB in a one-to-many or many-to-many association in a 
collection registry in response to passivation of the source EJB." The Office Action cites to page 
4, paragraph 1 of BEA Systems as disclosing this recitation; however, the cited portion of BEA 
Systems merely states that an EJB may be passivated by removing the EJB from the cache. BEA 
Systems does not disclose or suggest registering a collection of target EJBs in a collection 
registry in response to passivation of their source EJB. In fact, BEA Systems is silent as to 
whether or not anything happens to such a collection of target EJBs upon passivation of the 
source EJB. Accordingly, the rejection of Claim 10 should be withdrawn for at least this 
additional reason. 

Applicants likewise submit that the recitations of dependent Claims 4, 11-12, 18 and 22 
are also not taught or suggested by BEA Systems, but will not discuss these claims in detail in 
the interest of brevity. 
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VI. The Rejections Under 35 U.S.C. § 103 

Claims 5-8, 14-15 and 19-20 stand rejected as obvious under 35 U.S.C. § 103 in light of 
BEA Systems in view of the Sun article. (Office Action at p. 1 1, f 1 1). Applicants also 
respectfully traverse these rejections. 

As an initial matter, each of these rejections should be withdrawn for the same reasons 
that the rejections of the claims from which Claims 5-8, 14-15 and 19-20 depend should be 
withdrawn. In addition, the rejections under 35 U.S.C. § 103 should be withdrawn because Sun 
does not disclose the recitations of these claims. In particular, the Office Action cites to Sun as 
disclosing that "the developer is responsible for specifying the relationships between EJBs and 
that said relationships must be maintained using standard application programming interfaces." 
(See, e.g., Office Action at pp. 11-12, TJ1 1). Based on this statement, the Office Action states that 
it would have been obvious to one of ordinary skill in the art to implement the recitations cited in 
each of Claims 5-8, 14-15 and 19-20. The Office Action does not attempt to identify where any 
of the recitations of Claims 5-8, 14-15 and 19-20 can be found in either of the cited references, 
and thus fails to establish a prima facie rejection under 35 U.S.C. § 103 for at least this 
additional reason. Accordingly, Applicants respectfully submit that the rejections under 35 
U.S.C. 103 should also be withdrawn. 
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VII. Conclusion 

Inasmuch as the points and concerns raised in the Office Action have been addressed in 
full, Applicants respectfully request that this application is in condition to pass to issue, which 
action is respectfully requested. Should the Examiner have any matters of outstanding 
resolution, he is encouraged to telephone the undersigned at 919-854-1400 for expeditious 
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